IBIS Macromodel Task Group Meeting date: 25 February 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Ken Willis Kumar Keshavan Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Fangyi to email his draft GetWave2() BIRD to ATM. - Done. The version sent to ATM and posted to the work archives contains the changes discussed at the previous meeting and captured in the previous meeting's minutes. - Arpad to send an email reminder about a straw poll on the sampling issues in statistical flow AMI. - Done. Arpad noted that additional email discussion had been triggered by the reminder. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the February 18 meeting. Bob moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: DDR Clock Forwarding: Fangyi reviewed the draft version of the BIRD sent to ATM after the previous meeting. He noted that the Usage Rules: section for GetWave2_Exists now allows for both AMI_GetWave and AMI_GetWave2 to be provided in the same model. In addition, the Other Notes: section states that the model consumer, i.e., the user or EDA tool, decides which one to use if both are provided. Arpad asked if we should explicitly state that the EDA tool should not use both GetWave() and GetWave2() from the same model in the same simulation. Fangyi and Radek said they thought the existing language stating that the model consumer "decides whether to use AMI_GetWave or AMI_GetWave2 in simulation" was clear. Fangyi reviewed a new Note: he had added at the end of the AMI_GetWave2 section. It stated that: "AMI_GetWave2 shall be implemented only by Rx models that need to model clock forwarding. In DDR systems, DQ Rx models can implement AMI_GetWave2. DQS, command-address, control and clock Rx models shall not implement AMI_GetWave2 because these signals do not use forwarded clock." Arpad suggested that the second sentence be changed to: "In DDR systems, for example, DQ Rx models may implement AMI_GetWave2." Fangyi agreed and made the change. Bob noted that the Required: section of GetWave2_Exists should state that it is illegal before 7.1 (not 7.2), if we want this in 7.1. Fangyi/Arpad/Randy agreed this should go into the same version as the DC_Offset BIRD (BIRD197.7), which is version 7.1. Fangyi made the change. Fangyi said his search had revealed 193 places where AMI_GetWave was mentioned in IBIS 7.0. Radek noted his suggestion from the previous meeting that we might include a blanket statement that any use of AMI_GetWave could also apply to AMI_GetWave2. Arpad said this was a good suggestion, but we would have to review the document because it might not work in every instance. Fangyi said he was reviewing the document to find any instances for which the blanket statement would not work. Bob asked if we should state where within the specification these new sections should be added. Fangyi said he thought this might be an editorial issue, and he noted that recent BIRDs using the new template had not specified this information. Arpad said that info could be added to the Summary of Proposed Changes: section if necessary. Randy said the Editorial task group can figure out where to insert the sections. Other editorial changes, spelling, white space, etc., were suggested and made. Arpad and Fangyi agreed that it was not necessary to post this version to the ATM archives. The changes made during this meeting will appear in Fangyi's next major update. Discussion on "Gap in IBIS for sampling with statistical mode AMI models": Arpad noted that he had sent the reminder email about today's straw poll to choose a direction to pursue in a BIRD. The two choices, as defined in the email, were: a. Rx model tells the EDA tool where to sample b. IBIS specification describes the rules for the EDA tool on where to sample As this was just a straw poll to set direction, and Achronix had played a role in advancing the topic, all attending organization were allowed to vote. The straw poll went as follows: Achronix - method a Ansys - method a Cadence - method a (via email) Keysight - method a Mentor - method a Micron - method a SiSoft - method a (via email) SPISim - method a Teraspeed - method a Method a received 9 votes, method b received 0 votes. Hansel asked what the next step was. Arpad said it was to start work on a BIRD, and he noted that he thought Walter had said he'd be willing to draft a BIRD if method a were chosen. Hansel said he would like to propose some additional controls for the sampling. Since the IR matrix passed into AMI_Init contains the through channel and crosstalk responses, why not have the sampling point specified individually for each of the responses? Arpad noted that he would have expected the sampling point to be the same for all of them, but if there's a reason to control it independently then we can consider that during the process of drafting the BIRD. Hansel noted that this topic had come about as a result of trying to make AMI statistical mode work for DDR vendors not just SerDes, and offset sampling points for crosstalk might be useful. Fangyi asked what the definition of "sampling point" is for crosstalk? Hansel said the issue was in phase vs. out of phase crosstalk. Fangyi asked if that was a matter of the phase relationships between the different Txs, something that's already controlled by the EDA tool. Hansel said he would put together more information on the topic and present it at a later date. Arpad noted that there might be two ways for the model to provide the sampling point information to the EDA tool. It could provide an index into the waveform, or it could provide a floating point value for the absolute time. He asked if there was a reason to favor one over the other. Hansel said he thought that both could work, but he preferred an index. He said that if we decided to use a floating point value in UI or seconds then, depending on the way we pass the value, we may have to worry about the number of digits of precision, etc. Arpad and Randy said they thought a floating point number allowing us to specify a time in between the fixed sample times would be better than an integer index into the waveform. Arpad noted that these were details to be worked out in the BIRD. He also noted that while he had voted for method a, he would prefer we allow an option for the EDA tool to override the value returned by the model. - Curtis: Motion to adjourn. - Randy: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 03 March 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives